home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93b.txt / 000040_icon-group-sender _Wed Apr 28 12:56:19 1993.msg < prev    next >
Internet Message Format  |  1993-06-16  |  3KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 28 Apr 1993 13:06:06 MST
  2. Message-Id: <9304281953.AA17496@enlil.premenos.sf.ca.us>
  3. From: Ken Walker <kwalker@shara.premenos.sf.ca.us>
  4. Subject: var paramters
  5. To: icon-group@cs.arizona.edu
  6. Date: Wed, 28 Apr 93 12:56:19 PDT
  7. Mailer: Elm [revision: 66.25]
  8. Status: R
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10.  
  11. > from Richard L. Goerwitz:
  12. >
  13. > So-called "var" parameters in Pascal are a way of introducing side-
  14. > effects.  These are not permitted in Icon per se.  One usually does
  15. > not want or need them, although I have often wondered whether adding
  16. > them would be difficult - if they were done precisely as in Pascal
  17. > (i.e. not as in C, which might break Icon's type-safe scheme).
  18.  
  19. >From an implementation perspective, I'd prefer the in/out style of
  20. parameter passing, where the updated value of an out parameter is only
  21. copied back to the caller's variable upon return and suspend (should
  22. they be updated on failure?). There is also an advanatage from the
  23. language philosophy point of view: in the case of an out parameter,
  24. you can consider the call rather than the called procedure as being
  25. what updates a local variable passed as an argument; this means that 
  26. local variables are still only updated by the procedure they belong
  27. to, protecting their "local" status.
  28.  
  29. Those not interested in "technical" matters might want to skip the
  30. rest of the discussion.
  31.  
  32. I haven't investigated this in detail, but I think the following is
  33. what is needed to add in/out parameters to Icon. In the translator,
  34. the grammar for paramters must be updated and flags must be added
  35. to the symbol table to distinguish in, out, and in-out parameters.
  36. In the runtime system, in/out information must be added to procedure
  37. blocks. Invocation must keep a copy of variable refereces for out
  38. parameters and, on return, must assign the updated parameter values to
  39. those variables before popping the parameters from the stack. Suspend
  40. must also copy the updated out parameter values to the variables. The
  41. linker must be updated to produce the procedure blocks with the in-out
  42. information.
  43.  
  44. As one might expect, the compiler is a little harder because of
  45. optimizations. However, in-out parameters are easier than var
  46. parameters; type inference can be modified to handle var paramters,
  47. but it would make type inference more expensive. The modifications
  48. to the compiler's grammar and symbol table are similar to those of
  49. the translator for the interpreter. The abstract invocation of type
  50. inference must be updated to mirror the semantics of actual invocation;
  51. if you understand type inference, this is probably not harder than
  52. updating invocation in the run-time system. Non-optimized invocation
  53. can be handled similar to the way invocation is handled in the interpreter,
  54. though some of the inplementation conventions are different. One way to
  55. handle optimized procedure invocation is to not optimize if there are
  56. out parameters (but that's not much fun :-). The current case analysis
  57. for optimizing invocation is rather gross and optimizing out parameter
  58. passed will make it worse, but clearly it can be done.
  59.  
  60. Can anyone think of something I've missed?
  61.  
  62. Note: the preceding discussion should not be taken to mean that
  63. I'm considering trying to implement in/out parameters in the
  64. immediate future.
  65.  
  66.    Ken Walker, kwalker@premenos.sf.ca.us
  67.  
  68.